Cloud Database Engineer Practice Exam — Professional Cloud Database Engineer

The scenario requires secure connectivity to Cloud SQL for PostgreSQL from a corporate network VM without making any configuration changes to the Cloud SQL instance. The Cloud SQL instance is assigned a private RFC 1918 IP address (192.168.3.48) and has SSL disabled. Option C meets all requirements because the Cloud SQL Auth proxy authenticates connections using IAM credentials associated with a service account, eliminating the need to modify the Cloud SQL instance's authorized networks list (a configuration change that would be required for direct IP connections). The proxy automatically encrypts traffic in transit even when SSL is disabled on the database instance, and using the private IP address ensures all traffic remains on the private Google Cloud network, avoiding public internet exposure. No changes to the Cloud SQL instance are required, which aligns with the constraint given. Option Analysis: A. Incorrect. Using a Google username and password for JDBC connections to Cloud SQL is not a supported native authentication method. Additionally, connecting via the public IP address would require adding the corporate VM's public IP to the Cloud SQL instance's authorized networks, which is a prohibited database configuration change. This approach also exposes the database to public internet risk and lacks built-in encryption since SSL is disabled on the instance. B. Incorrect. Directly connecting to the private IP address with a database username and password requires adding the corporate network IP range to the Cloud SQL instance's authorized networks, which is a configuration change prohibited by the scenario. Additionally, since SSL is disabled on the instance, this connection would transmit data unencrypted, creating a security risk. C. Correct. The Cloud SQL Auth proxy uses service account IAM credentials to authenticate and authorize connections, so no changes to the Cloud SQL instance's authorized networks or SSL settings are required. Connecting via the private IP address ensures traffic stays on the private, secure Google Cloud network, which is appropriate for a corporate network connected to GCP via VPN or Cloud Interconnect. The proxy also handles in-transit encryption automatically, even with SSL disabled on the database instance. D. Incorrect. The given Cloud SQL IP address is a private RFC 1918 address, and there is no indication a public IP is enabled for the instance. Using a public IP is unnecessary for corporate network access and introduces unnecessary public internet exposure, even when using the auth proxy. This approach also does not align with the provided private IP configuration of the Cloud SQL instance. Key Concepts: 1. Cloud SQL Auth Proxy Functionality: The Cloud SQL Auth proxy provides secure, IAM-authenticated access to Cloud SQL instances without requiring manual IP allowlisting or SSL configuration on the database instance itself. It manages encryption in transit and authorization via IAM permissions, reducing the need for instance-level configuration changes. 2. Cloud SQL Private IP Connectivity: Private IP assigns Cloud SQL instances an address from a private RFC 1918 range, ensuring traffic between clients and the instance stays on Google's private network. It requires private connectivity between the client network and GCP, such as VPN or Cloud Interconnect, which is standard for corporate network access to GCP resources. 3. Cloud SQL Instance Configuration Change Controls: Modifications to authorized networks, IP address settings, or SSL configurations are considered instance-level database changes. These changes are often restricted in change-controlled environments, making access methods that avoid such changes (like the auth proxy) the preferred solution for compliant access. References: About the Cloud SQL Auth Proxy, https://cloud.google.com/sql/docs/postgres/connect-auth-proxy Private IP for Cloud SQL, https://cloud.google.com/sql/docs/postgres/private-ip

This question assesses knowledge of Google Cloud SQL high availability (HA) and disaster recovery best practices, a core domain for the Professional Cloud Database Engineer certification. The scenario requires 24/7 global availability for Cloud SQL workloads, so solutions must minimize downtime and data loss while following official Google guidance. The correct answers, D and E, address core recoverability requirements: scheduled automated backups provide a reliable baseline of instance state for recovery from outages or data loss, while point-in-time recovery extends that capability to allow granular recovery to any timestamp within the retention window, drastically reducing recovery point objective (RPO) to near-zero for most failure scenarios. Both configurations are mandatory components of Google's recommended Cloud SQL HA strategy for business-critical 24/7 workloads. Option Analysis: A. Incorrect. Manual backups are user-initiated, ad-hoc operations that rely on human intervention to execute, creating risk of gaps in backup coverage that can lead to avoidable data loss for 24/7 workloads. Google explicitly recommends automated backups over manual backups for regular HA and disaster recovery workflows, as manual backups are intended only for one-off use cases such as pre-change snapshots, not continuous availability preparedness. B. Incorrect. Deploying an on-premises PostgreSQL instance for HA introduces unnecessary hybrid architecture complexity, increases latency for global users, and is not a supported or recommended HA configuration for Cloud SQL. Cloud SQL natively provides managed cross-zone HA replicas and recovery workflows that eliminate the need for on-premises secondary instances for cloud-native workloads. C. Incorrect. Single zone availability for Cloud SQL instances means the instance and associated backup storage are tied to a single availability zone, with no redundancy if that zone experiences an outage. This configuration cannot support 24/7 global availability requirements, as a zone failure would result in extended downtime. Google recommends regional (multi-zone) instance deployment for HA workloads. D. Correct. Point-in-time recovery (PITR) for Cloud SQL uses persistent write-ahead logs (WAL) retained for a user-defined window up to 35 days, allowing recovery to any second within that window. This capability drastically reduces RPO, supporting recovery from accidental data deletion, corruption, or outages with minimal data loss, which is critical for 24/7 business-critical workloads. PITR is explicitly listed as a Google-recommended practice for Cloud SQL HA. E. Correct. Scheduled automated backups are managed by Google Cloud, run on a predefined cadence selected by the user, and are stored redundantly across multiple availability zones independent of the primary instance. They serve as the baseline recovery mechanism for Cloud SQL instances, and are a prerequisite for enabling PITR. Automated backups eliminate the risk of human error associated with manual backups, making them ideal for supporting 24/7 availability requirements. Key Concepts: 1. Cloud SQL High Availability Best Practices: This core certification domain covers configurations required to achieve low recovery time objective (RTO) and recovery point objective (RPO) for Cloud SQL workloads, including automated backups, PITR, and multi-zone instance deployment to support continuous availability for business-critical use cases. 2. Recovery Time Objective (RTO) and Recovery Point Objective (RPO): These are core disaster recovery metrics: RTO is the maximum acceptable duration of downtime after an outage, RPO is the maximum acceptable amount of data loss after an outage. Automated backups and PITR directly reduce both metrics to meet the strict requirements of 24/7 global workloads. 3. Cloud SQL Backup Types: This concept covers the difference between automated and manual backups, including use cases, redundancy, and integration with other recovery features. Automated backups are designed for continuous disaster recovery preparedness, while manual backups are intended for ad-hoc, one-off use cases. References: About Cloud SQL backups, Best practices for designing high availability systems on Cloud SQL

The question outlines two critical requirements: minimal disruption to the existing architecture, and completion of migration within a six-month timeline for a highly transactional Oracle footprint currently running on VMware. The optimal solution prioritizes compatibility with the existing on-premises VMware stack to avoid rearchitecting applications or databases while moving workloads natively to Google Cloud. Google Cloud VMware Engine delivers a fully managed, natively integrated VMware environment on Google Cloud infrastructure, allowing direct lift-and-shift of existing VMware workloads without modifying virtual machines, applications, or database configurations. This approach preserves all existing VMware tooling, operational processes, and Oracle performance characteristics, eliminating disruption to the current architecture and enabling fast migration to meet the six-month deadline. Option Analysis: A. Correct. Google Cloud VMware Engine runs the same VMware hypervisor, vCenter, vSAN, and NSX tooling used in the on-premises environment. Migrating VMware-based Oracle and application workloads to GCVE requires no refactoring, no hypervisor conversion, and minimal reconfiguration, directly meeting the minimal disruption requirement. Highly transactional Oracle performance is fully preserved, and the migration can be completed well within the six-month timeline using standard VMware migration tools like vMotion. B. Incorrect. Migrating to Compute Engine requires converting VMware virtual machine disk formats to GCE-compatible images, reconfiguring network, storage, and identity access to align with GCE constructs rather than existing VMware constructs. This adds significant migration effort, requires changes to the underlying architecture, and introduces more disruption than moving to a compatible VMware environment, so it does not meet the minimal disruption requirement. C. Incorrect. This option is fundamentally invalid for two reasons: first, Cloud SQL is a managed relational database service that does not support Oracle database engines, so it cannot host the Oracle workload. Second, Cloud SQL is designed to host databases, not applications, so migrating applications to Cloud SQL is not technically possible. D. Incorrect. Migrating to GKE requires containerizing both the applications and the highly transactional Oracle database, which is a major rearchitecture effort that requires extensive refactoring, testing, and adjustment of Oracle operational processes for containerized environments. This introduces significant disruption and is unlikely to be completed within the six-month timeline, so it fails to meet the stated requirements. Key Concepts: 1. Google Cloud VMware Engine (GCVE) use cases: GCVE is a fully managed VMware as a Service (VaaS) offering on Google Cloud that enables lift-and-shift migration of on-premises VMware workloads without rearchitecting, making it the preferred choice for minimal-disruption migrations of VMware-tied enterprise workloads including Oracle databases. 2. Minimal-disruption migration best practices: For enterprise workloads tightly coupled to specific on-premises infrastructure stacks such as VMware, prioritizing migration to a compatible managed cloud environment eliminates the need for refactoring, reduces migration risk, and accelerates migration timelines compared to rearchitecting to native cloud services. 3. Oracle on GCP deployment options: Oracle workloads can be deployed on multiple GCP environments, with deployment choice aligned to existing on-premises architecture and migration requirements. GCVE is the optimal deployment target for Oracle workloads already running on VMware to preserve existing configurations, tooling, and performance. References: Google Cloud VMware Engine Overview, https://cloud.google.com/vmware-engine/docs/overview Best practices for running Oracle workloads on Google Cloud VMware Engine

The scenario describes unexpected high read latency on a multi-region Cloud Spanner instance following an application version update, requiring targeted performance diagnosis as the first resolution step. The suggested answer C aligns with core Professional Cloud Database Engineer troubleshooting workflows for Cloud Spanner, where you first diagnose the root cause of observed latency before implementing fixes. The SPANNER_SYS.READ_STATS* tables capture granular, end-to-end telemetry for all read operations in Spanner, including latency percentiles, lock wait times, access key ranges, replica routing details, and read type (point read, range read, transactional read), which is critical for identifying if the new application version introduced patterns like hot keys, improper read consistency settings, or misrouted reads that are driving higher latency in the multi-region deployment. Option Analysis: A. Incorrect. Query parameters improve performance by enabling query plan caching for repeated parameterized SQL queries, but this is a targeted fix for specific inefficient queries, not a diagnostic step for generalized high read latency. There is no evidence yet that uncached query plans are the root cause, so this is premature and does not address the diagnostic requirement. B. Incorrect. Converting a multi-region Spanner instance to single region would break the global chat application's requirement for multi-regional availability and low latency for distributed global users. This is a drastic, unsupported change without prior root cause analysis, and would not resolve the latency introduced specifically by the new application version. C. Correct. The SPANNER_SYS.READ_STATS* introspection tables are purpose-built for diagnosing Cloud Spanner read latency issues. They capture data for all read operations, including both SQL reads and native API point/range reads common in chat applications, as well as details specific to multi-region deployments like replica serving location and consistency mode impacts. Querying these tables lets you directly isolate the root cause of the post-update read latency to implement the correct fix. D. Incorrect. The SPANNER_SYS.QUERY_STATS* tables only capture performance data for SQL query execution, and do not include telemetry for non-SQL read operations executed via the Spanner RPC API, which are widely used in low-latency chat applications. Since the issue is generalized high read latency, not just slow SQL queries, these tables do not provide the complete dataset needed for diagnosis. Key Concepts: 1. Cloud Spanner Introspection Tables: The SPANNER_SYS schema contains built-in telemetry tables for monitoring and troubleshooting all aspects of Spanner performance, with separate tables tailored for read operations, query operations, transaction operations, and storage usage, as tested in the Professional Cloud Database Engineer exam domain of managed database troubleshooting. 2. Cloud Spanner Read Operation Types: Spanner supports two categories of read operations: SQL query reads, and native API point/range reads that do not use SQL syntax. General read latency issues require analysis of all read types, not just SQL queries, to identify root cause. 3. Multi-region Spanner Performance Diagnostics: Multi-region Spanner instances serve reads from geographically distributed replicas, so read latency can be impacted by application-level changes to consistency settings, access patterns, or routing logic, requiring read-specific telemetry to isolate issues. References: Troubleshoot read latency in Cloud Spanner, Read stats tables

The scenario outlines requirements to migrate PostgreSQL databases from on-premises and AWS environments to Cloud SQL, follow Google recommended practices, use Google native migration tools, and monitor migration progress to support cutover planning. Google's Database Migration Service (DMS) is the official, fully managed native migration tool for this use case. It natively supports homogeneous PostgreSQL migrations from both on-premises deployments and AWS-hosted PostgreSQL sources such as Amazon RDS PostgreSQL. DMS provides both one-time full load migrations and continuous change data capture (CDC) replication to enable minimal downtime migrations, and includes built-in monitoring metrics, dashboards, and cutover readiness checks to track migration health and replication lag, directly meeting all stated requirements. No third-party or partner tools are required for this workflow, so using DMS for all migrations is the correct approach. Option Analysis: A. Correct. This option aligns with all requirements in the scenario. Database Migration Service is Google's native, recommended tool for migrating PostgreSQL databases to Cloud SQL, supports both on-premises and AWS PostgreSQL sources, natively provides both full load and ongoing CDC replication for low downtime migrations, and includes built-in monitoring capabilities to track migration progress and validate cutover readiness as required. B. Incorrect. Database Migration Service natively supports continuous CDC-style migrations for PostgreSQL to Cloud SQL, so third-party or partner tools are not required for CDC workloads. This option unnecessarily introduces non-native tools which violates the requirement to use Google native tools where possible, and does not follow Google recommended practices. C. Incorrect. This option specifies generic, non-native data replication and CDC tools, which do not meet the requirement to use Google native migration tools. Generic tools require additional operational overhead, lack native integration with Cloud SQL and Google Cloud monitoring, and are not the recommended approach for this migration scenario. D. Incorrect. The scenario explicitly requires using Google native data migration tools, and Database Migration Service alone supports all required migration use cases for PostgreSQL to Cloud SQL from the specified sources. Partner tools are unnecessary for this workload, so this option deviates from Google recommended best practices for native tool usage. Key Concepts: 1. Google Cloud Database Migration Service (DMS) core functionality: DMS is a fully managed, Google-native migration service designed for homogeneous and heterogeneous migrations to Cloud SQL, AlloyDB, and Spanner. It supports both one-time full load migrations and ongoing CDC replication for minimal downtime cutovers, with built-in monitoring for migration progress and replication health. 2. Cloud SQL migration best practices: Google recommends prioritizing native Google Cloud migration tools like DMS for Cloud SQL migrations to ensure native integration with Google Cloud's security, monitoring, and management ecosystem, reduce operational overhead, and align with supported, validated migration workflows. 3. Minimal downtime migration cutover requirements: Successful low-downtime migrations require continuous replication of changes between source and target databases, ongoing monitoring of replication lag and data consistency, and validation of cutover readiness, all of which are natively supported by DMS for PostgreSQL migrations. References: Database Migration Service Documentation, https://cloud.google.com/database-migration/docs Migrate a PostgreSQL database to Cloud SQL